IBX Connect - Validation and synchronous error
handling
Each document sent to IBX Connect results in a synchronous response message back to the calling application. If the response includes an HTTP 200 code then the message passed the inbound validation successfully, the TCP/IP connection is closed and processing of the message within the IBX Business Network has started. If the response does not include the HTTP 200 code then something went wrong and there can be various reasons for this.
Server unavailability
An HTTP response code 500 is received when connections to
the IBX Connect servers are failing due to planned or
unplanned downtime. The format of the HTTP response in this
case depends on the application trying to connect. Apart from
scheduled downtimes for maintenance the availability of the IBX
Connect platform is guaranteed by service level agreements
(SLA) with 99% uptime all around the clock. In case of
unplanned downtime due to technical difficulties customers are
notified about status and expected resolution time via the IBX
Subscriptions service.
To avoid loss of data trading partners are urged to have a
minimum of transaction monitoring on their side that makes sure
documents are resent after a connection failed with status code
500.
Basic inbound validation
When the request has passed the IBX firewall and a connection is established then the information in the HTTP header and the XML message in the HTTP body is validated. Follow the link below to see some example scenarios where transactions are rejected, an HTTP response code 4xx with a more specified SOAP response is returned and the connection is closed.
Duplicate check
The duplicate check within IBX Connect ensures that documents are always received only once and that duplicates are not processed and sent to their receiver again. The default duplicate check is based on the combination of senderID and messageID and applies to all kind of documents. For orders this check is extended to include also the ordernumber. By default non unique documents are rejected, an HTTP response code 400 with a more specified SOAP response is returned and the connection is closed. On request this can be changed to any other valid HTTP response code with a customer specific description in the SOAP response.
Extended business rules validation
Invoices and CreditNotes following specific standards like the European PEPPOL, the Norwegian EHF or the Danish OIOUBL standard are in addition to a basic XML schema validation also validated against these standards' particular sets of business rules. Depending on which standard is applying to a business relationship between the partners sending and receiving Invoices/CreditNotes these documents can be rejected by IBX Connect, if their content doesn´t fulfill all requirements. In this case an HTTP response code 4xx with a more specified SOAP response is returned and the connection is closed as described above. Additionally both sender and receiver of the document can be configured to receive an email with details for the rejected document and the reason for the rejection.
Invoice Matching
IBX Invoice Matching is a feature that can be activated per buyer and supplier and means that invoices are matched and validated against orders and are only accepted and submitted to the buyer if certain rules are observed. Prerequisite is that each Invoice is refering to only one purchase order which must have been sent via IBX Connect before. Invoice Matching is performed asynchronously which means that invoice messages are received, an HTTP response code "200" is returned to the sending server and the sender is informed via email.